Web services are reusable software components that may be accessed by applications over a network for the delegation of sub-functionality. Web services are made available for online access by deployment of those web services on a server that is compatible with the web service specification. The specification of a web service typically comprises a description and interface and invocation (binding) information, which is published in a web services directory. Applications can thus search for web services of interest from a web services directory, select web service interfaces that match specific criteria, and invoke web services using published binding and connectivity information.
Web services are typically described using the Web Services Definition Language (WSDL) specification, which is an XML-based language for defining messages that provide an abstract definition of data being transmitted and operations provided by a web service to transmit the messages. Four types of communication are defined that relate to a service's operation (endpoint): the endpoint receives a message (one-way), the endpoint sends a message (notification), the endpoint receives a message and sends a correlated message (request-response), and the endpoint sends a message and receives a correlated message (solicit-response).
Operations are grouped into port types, which describe abstract end points of a web service such as a logical address under which an operation can be invoked. A WSDL message element defines the data elements of an operation. XML Schema syntax is used to define platform-independent data types which messages can use. Each message can consist of one or more parts. The parts may be compared to the parameters of a function call in a traditional programming language. Concrete protocol bindings and physical address port specifications complete a web service specification.
FIG. 1 shows a method for accessing web services. At step 110, one or more web services relevant to a required functionality are discovered by an application. Discovery is typically performed by searching a web services directory. One or more subsets of the web services that are discovered in step 110 are selected based on certain selection criteria, at step 120. While each subset of web services selected is potentially able to service the required functionality, the exact detail (e.g., workflow) is unknown at this stage. Candidate workflows are composed or generated from the web services selected in step 120, at step 130. The candidate workflows specify the data and control flows between the web services in each subset of web services. At step 140, the web services for the most promising workflow are orchestrated. Orchestration requires selection of web service instances to be used in the most promising workflow. A web service instance comprises a specific instance of a more generic web service. For example, “AmazonBookPurchaseService” and “Bames&NobleBookPurchaseService” are instances of the generic web service “OnlineBookPurchaseService”. Control and data flows may be rearranged and optimized based on the physical details of the workflow. At step 150, a binding mechanism is selected for access by an application. The binding mechanism is typically selected from various programmatic mechanisms such as Simple Object Access Protocol (SOAP), Simple Mail Transfer Protocol (SMTP), local Java access, etc. SOAP is a XML-based protocol for the exchange of information in a distributed environment. The web service/s is/are invoked with input parameters, if any, at step 160.
Applications may combine some of the stages (e.g., discovery, selection and composition) and/or hardcode certain actions.
The Web Services Invocation Framework (WSIF) provides a mechanism for invoking web services without committing to physical details/binding relating to where such web services are located. Rather, binding is resolved at execution time based on user-specifiable criteria. While providing a means for abstracting a single invocation of a web service, the WSIF does not provide a mechanism for reusing information for multiple invocations of a web service from an application or for invocation of a web service by multiple applications running on a client platform.
The Universal, Description, Discovery and Integration (UDDI) directory provides a mechanism to search for web services on a remote web service registry. However, the UDDI directory does not provide a mechanism for reusing information for multiple invocations of a web service from a single application or for invocation of a web service by multiple applications running on a client platform.
Applications typically manage information relating to web services individually. However, duplication and redundancy of information and software program code for housekeeping and information processing to select and invoke web services results when information common to multiple web services is required by an application and/or when multiple applications running on the same client platform use the same web services. As information relating to web services access may change frequently, the foregoing may result in poor maintainability of applications.
A need thus exists for management of information relating to web services used by one or more applications running on a client platform.